Modern cryptography and network security systems often employ certificate-based authentication mechanisms to verify that a public key belongs to a particular computing device associated with a particular entity or person. A “public key” or “identity” certificate is signed data structure (e.g., an electronic document) which incorporates a digital signature to bind a public key with an identity (i.e., information such as the name of a person or an organization, their address, device address, and so forth). In a typical public key infrastructure (PKI) scheme, Certification Authority (CA) generates or “issues” certificates that are signed with the private key of the CA. The issuer CA also defines a validity period of the certificate. In some cases, a certificate can be revoked even before this validity period expires. In internetworking and computer network engineering, Request for Comments (RFC) documents are a series of memoranda encompassing new research, innovations, and methodologies applicable to Internet technologies. The Internet Engineering Task Force (IETF) adopts some of the proposals published in RFCs as Internet standards. One may retrieve almost any individual, published RFC via the following URL: http://www.rfc-editor.org/rfc. The Internet Engineering Task Force (IETF) Request for Comments (RFC) 3280 defines some of the reasons for revoking a certificate. For example, a certificate may be revoked when the certificate's corresponding private key is compromised, when the affiliation of the owner has changed, etc. Thus, the process of validating certificates not only involves verifying the issuer CA's signature and the certificate's validity period, but also involves checking the certificate's revocation status. One technique for checking the certificate's revocation status involves checking a Certificate Revocation List (CRL).
CRLs are widely used to distribute information about revoked certificates. A CA generates or issues a certificate revocation list (CRL) to report revocation of any certificates issued by that CA. The issuer CA can generate a CRL either periodically (i.e., after a clearly defined timeframe) and/or immediately after a certificate has been revoked. A CRL typically includes information about the identity of the issuer of the CRL, the certificate serial number, the effective date of the CRL, the expected next update of the CRL, the algorithm used to sign the list of revoked certificates, a list of certificate serial numbers which identify certificates that have been revoked, and the effective date when each certificate was revoked and a digital signature of the body of the CRL generated by the issuing CA that can be used to validate the CRL prior to trusting accuracy of its content. It is desirable that entities have the most current CRL(s) when performing certificate validation. As such, entities should receive updates to CRLs (i.e., updated CRLs) as soon as possible after the issuer CA updates them. Given the large amount of information in a CRL, and the fact that updates to the CRL need to be retrieved or downloaded frequently by end-users to insure the timeliness of the revocation information, the process of retrieving CRLs can be quite costly in terms of network resources.
Implementing certificate-based authentication mechanisms in an ad hoc network can present a number of challenges given the unique properties of ad hoc networks. For example, because an ad hoc network is not necessarily connected to the infrastructure at all times, infrastructure entities, including a CRL distribution point, may not always be accessible. In addition, it is desirable that the amount data overhead in communications be limited due to the bandwidth limitations in ad hoc networks.
One particular challenge to implementing certificate-based authentication mechanisms in ad hoc networks relates to providing nodes with CRLs (and updates to those CRLs). In ad hoc networks, nodes can not always retrieve CRLs using standard CRL retrieval schemes since nodes do not always have access to infrastructure. In many cases, each node in the ad hoc network will not have stored the same versions of the CRL(s). This can happen, for example, when one of the nodes in the ad hoc network has not connected to the infrastructure since the most recent CRL update.
Other techniques that have been developed for providing CRLs to nodes in an ad hoc network also suffer from other problems including: unnecessary data overhead (especially if there are CRLs from more than one CA), multiple broadcasts of the same CRL(s) from different nodes, and preventing nodes in the ad hoc network from obtaining the latest available CRL.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.